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Abstract 

Reuse of products, processes and other knowledge will be the key to enable the software industry 
to achieve the dramatic improvement in productivity and quality required to satisfy the anticipated 
growing demands. Although experience shows that certain kinds of reuse can be successful, gen- 
eral success has been elusive. A software life-cycle technology which allows comprehensive reuse 
of all kinds of software-related experience could provide the means to achieving the desired order- 
of-magnitude improvements. In this paper, we introduce a comprehensive framework of models, 
model-based characterization schemes, and support mechanisms for better understanding, evaluat- 
ing, planning, and supporting all aspects of reuse. 
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1. INTRODUCTION 


The existing gap between demand and our ability to produce high quality software cost- 
effectively calls for an improved software development technology. A reuse oriented development 
technology can significantly contribute to higher quality and productivity. Quality should 
improve by reusing all forms of proven experience including products, processes as well as quality 
and productivity models. Productivity should increase by using existing experience rather than 
creating everything from scratch. 

Reusing existing experience is a key ingredient to progress in any discipline. Without 
reuse everything must be re-learned and re-created; progress in an economical fashion is 
unlikely. Reuse is less institutionalized in software engineering than in any other engineering dis- 
cipline. Nevertheless, there exist successful cases of reuse, i.e. product reuse. The potential 

payoff from reuse can be quite high in software engineering since it is inexpensive to store and 
reproduce software engineering experience compared to other disciplines. 

The goal of research in the area of reuse is to develop and support systematic approaches 
for effectively reusing existing experience to maximize quality and productivity. A number of dif- 
ferent reuse approaches have appeared in the literature (e.g., [10, 12, 14, 17, 18, 19, 20, 26, 27, 
29]). 

This paper presents a comprehensive framework for reuse consisting of a reuse model, char- 
acterization schemes based upon this model, the improvement oriented TAME environment model 
describing the integration of reuse into the enabling software development processes, mechanisms 
needed to support comprehensive reuse in the context of the TAME environment model, and (par- 
tial) prototype implementations of the TAME environment model. From a number of important 
assumptions regarding the nature of software development and reuse we derive four essential 
requirements for any useful reuse model and related characterization scheme (Section 2). We illus- 
trate that existing models and characterization schemes only partially satisfy these essential 
requirements (Section 3). We introduce a new reuse model which is comprehensive in the sense 
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that it satisfies all four reuse requirements, and use it to derive a reuse characterization scheme 
(Section 4). Finally, we point out the mechanisms needed to support effective reuse according to 
this model (Section 5). Throughout the paper we use examples of reusing generic Ada packages , 
design inspections, and cost models to illustrate our approach. 


2. SCOPE OF COMPREHENSIVE REUSE 

The reuse framework presented in this paper is based on a number of assumptions regarding 
software development in general and reuse in particular. These assumptions are based on more 
than fifteen years of analyzing software processes and products [2, 5, 7, 8, 9, 23]. From these 
assumptions we derive four essential requirements for any useful reuse model and related charac- 
terization scheme. 

2.1. Software Development Assumptions 

According to a common software development project model depicted in Figure 1, the goal 
of software development is to produce project deliverables (i.e,, project output) that satisfy pro- 
ject needs (i.e., project input) [30]. This goal is achieved according to some development process 
model which coordinates the interaction between available personnel, practices, methods and 
tools. 
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Figure 1: Software Development Project Model 

With regard to software development we make the following assumptions: 

• Software development needs to be viewed as an ’experimental’ discipline: An evolu- 
tionary model is needed which enables organizations to learn from each development and incre- 
mentally improve their ability to engineer quality software products. Such a model requires the 
ability to define project goals; select and tailor the appropriate process models, practices, 
methods and techniques; and capture the experiences gained from each project in reusable form. 
Measurement is essential. 

• A single software development approach cannot be assumed for all software 
development projects: Different project needs and other project characteristics may suggest 
and justify different approaches. The potential differences may range from different develop- 
ment process models themselves to different practices, methods and tools supporting these 
development process models to different personnel. 

• Existing software development approaches need to be tailorable to project needs 
and characteristics: In order to reuse existing development process models, practices, 
methods and tools across projects with different needs and characteristics, they need to be 
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tailorable. 


2.2. Software Reuse Assumptions 

Reuse oriented software development assumes that, given the project-specific needs 5 x J for 
an object we consider reusing some already existing object ’x^’ instead of creating V from 
scratch. Reuse involves identifying a set of reuse candidates ’x^’, *x * from an experience base, 
evaluating their potential for satisfying ’x’, selecting the best-suited candidate ’x^’, and - if 
required - modifying the selected candidate ’x^’ into 5 x’. Similar issues have been discussed in 
[16]. In the case of reuse oriented development, ’x 5 is not only the specification for the needed 
object V, but also the specification for all the mentioned reuse activities. 

As we learn from each project which kinds of experience are reusable and why, we can 
establish better criteria for what should and what shouldn’t be made available in the experience 
base. The term experience base suggests that anticipate storage of all kinds of software related 
experience, not just products. The experience base can be improved from inside as well as out- 
side. From inside, we can record experience from ongoing projects which satisfies current reuse 
criteria for future reuse, and we can re-package existing experience through various mechanisms 
in order to better satisfy our current reuse criteria. From outside, we can infuse experience which 
exists out-side the organization into the experience base. It is important to note that the 
remainder of this paper deals only with the reuse of experience available in an experience base 
and the improvement of such an experience base from inside (shaded portion of Figure 2). 
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Figure 2: Reuse Oriented Software Development Model 

With regard to software reuse we make the following assumptions: 

• All experience can be reused: Traditionally, the emphasis has been on reusing concrete 
objects of type ’source code’. This limitation reflects the traditional view that software equals 
code. It ignores the importance of reusing all kinds of software-related experience including 
products, processes, and other knowledge. The term ’product’ refers to either a concrete docu- 
ment or artifact created during a software project, or a product model describing a class of 
concrete documents or artifacts with common characteristics. The term ’process’ refers to 
either to a concrete activity or action - performed by a human being or a machine - aimed at 
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creating some software product, or a process model describing a class of activities or actions 
with common characteristics. The phrase ’other knowledge’ refers to anything useful for 
software development, including quality and productivity models or models of the application 
being implemented. 

The reuse of ’generic Ada packages’ represents an example of product reuse . Generic Ada pack - 
ages represent templates for instantiating specific package objects according to a parameter 
mechanisms . The reuse of ’ design inspections’ represents an example of process reuse . Design 
inspections are off-line fault detection and isolation methods applied during the module design 
phase . They can be based on different techniques for reading (e.g., ad hoc, sequential , control 
flow oriented, stepwise abstraction oriented). The reuse of 1 cost models’ represents an example 
of knowledge reuse. Cost models are used in the estimation, evaluation and control of project 
cost They predict cost (e.g., in the form of staff-months ) based on a number of characteristic 
project parameters (e.g., estimated product size in KLoC, product complexity, methodology 
level). 

• Reuse typically requires some modification of the object being reused: Under the 
assumption that software developments may be different in some way, modification of experi- 
ence from prior projects must be anticipated. The degree of modification depends on how 
many, and to what degree, existing object characteristics differ from the needed ones. The time 
of modification depends on when the reuse needs for a project or class of projects are known. 
Modification can take place as part of actual reuse (i.e., the ’modify’ within the reuse process 
model of Figure 2) and/or prior to actual reuse (i.e., as part of the re-packaging activity in 
Figure 2). 


To reuse an Ada package ’ list of integers’ to organize a ’list of reals’ we need to modify it We 
can either modify the existing package by hand, or we can use a generic package ’list 1 which can 
be instantiated via a parameter mechanism for any base type. 

To reuse a design inspection method across projects characterized by significantly different fault 
profiles, the underlying reading technique may need to be tailored to the respective fault profiles . 
If ’ interface faults’ replace ’ control flow faults’ as the most common fault type, we can either 
select a different reading technique all together (e.g., step-wise abstraction instead of control- 
flow oriented) or we can establish specific guidelines for identifying interface faults . 

To reuse a cost model across projects characterized by different application domains, we may 
have to change the number and type of characteristic project parameters used for estimating 
cost as well as their impact on cost. If ’ commercial software ’ is developed instead of ’ real-time 
software we may have to consider re-defining ’ estimated product size ’ to be measured in terms 
of ’function points’ instead of ’ lines of code ’ or re-computing the impact of the existing parame- 
ters on cost. Using a cost model effectively implies a constant updating of our understanding of 
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the relationship between project parameters and cost. 


Analysis is necessary to determine when and if reuse is appropriate: The decision to 
reuse existing experience as well as how and when to reuse it needs to be based on an analysis 
of the payoff. Reuse payoff is not always easy to evaluate [l] . We need to understand (i) the 
reuse needs, (ii) how well the available reuse candidates are qualified to meet these needs, and 
(iii) the mechanisms available to perform the necessary modification. 


Assume the existence of a set of Ada generics which represent application-specific components 
of a satellite control system. The objective may be to reuse such components to build a new 
satellite control system of a similar type , but with higher precision. Whether the existing gener- 
ics are suitable depends on a variety of characteristics: Their correctness and reliability, their 
performance m prior instances of reuse, their ease of integration into a new system, the poten- 
tial for achieving the higher degree of precision through instantiation, fAc degree of change 
needed, and the existence of reuse mechanisms that support this change process. Candidate 
Ada generics may theoretically be well suited for reuse; however, without knowing the answers 
to these questions, they may not be reused due to lack of confidence that reuse will pay off. 

Assume the existence of a design inspection method based on ad-hoc reading which has been 
used successfully on past satellite control software developments within a standard waterfall 
model. The objective may be to reuse the metAorf in fAe context of the Cleanroom development 
method (22, 25 j. In this case, the method needs to be applied in the context of a different life- 
cycle model, different design approach, and different design representations . WAefAer and how 
the existing method can be reused depends on our ability to tailor the reading technique to the 
stepwise refinement oriented design technique used in Cleanroom, and the require*/ intensity of 
reading due to the omission of developer testing. This results in the definition of the stepwise 
abstraction oriented reading technique [llj. 

Assume the existence of a cost model that has been validated for the development of satellite 
control software based on a waterfall life-cycle model, functional decomposition oriented design 
techniques, and functional and structural testing. The objective may be to reuse the model in 
the context of Cleanroom development. Whether the cost model can be reused at all, how it 
needs to be calibrated, or whether a completely different model may be more appropriate 
depends on whether the model contains the appropriate variables needed for the prediction of 
cost change or whether they simply need to be re-calibrated. This question can only be answered 
through thorough analysis of a number of Cleanroom projects. 


Reuse must be integrated into the specific software development: Reuse is intended to 
make software development more effective. In order to achieve this objective we need to tailor 
reuse practices, methods and tools towards the respective development process. 


We have to decide when and how to identify , modify and integrate existing Ada packages. If we 
assume identification of Ada generics by name, and modification by the generic parameter 
mechanism, we require a repository consisting of Ada generics together with a description of the 
instantiation parameters. If we assume identification by specification, and modification of the 



generic’* code by Jiand, we require a suitable specification of each generic , a definition of 
semantic closeness of specifications so we can find suitable reuse candidates , and the appropri- 
ate source code documentation to allow for ease of modification . In the case of identification 
fry specification we may consider identifying reuse candidates at high-level design (i. e., when the 
component specifications for the new product exist) or even when defining the requirements . 

We have to decide on how often t when, and how design inspections should be integrated into the 
development process . If we assume a waterfall-based development life-cycle, we need to deter- 
mine how many design inspections need to be performed and when (e.g. f once for all modules at 
the end of module design , once for all modules of a subsystem, or once for each module). We 
need to state which documents are required as input to the design inspection , what results are 
to be produced , what actions are to be taken, and when , in case the results are insufficient, and 
who is supposed to participate. 

We have to decide when to initially estimate cost and when to update the initial estimate. If we 
assume a waterfall-based development life-cycle, we may estimate cost initially based on 
estimated product and process parameters (e.g., estimated product size). After each milestone, 
the estimated cost can be compared with the actual cost. Possible deviations are used to correct 
the estimate for the remainder of the project. 


2.3* Software Reuse Model Requirements 

The above software reuse assumptions suggest that ’reuse’ is a complex concept. We need to 
build models and characterization schemes that allow us to define and understand, compare and 
evaluate, and plan the reuse needs, the reuse candidates, the reuse process itself, and the potential 
for effective reuse. Based upon the above assumptions, such models and characterization schemes 
need to satisfy the following four requirements: 

• Applicable to all types of reuse objects: We want to be able to include products, processes 
and all other kinds of knowledge such as quality and productivity models. 

• Capable of modeling reuse candidates and reuse needs: We want to be able to capture 
the reuse candidates as well as the reuse needs in the current project. This will enable us to (i) 
judge the suitability of a given reuse candidate based on the distance between the characteris- 
tics of the reuse needs and the reuse candidate, and (ii) establish criteria for useful reuse candi- 
dates based on anticipated reuse needs. 

• Capable of modeling the reuse process itself: We want to be able to (i) judge the ease of 

• Definitions of semantic closeness can be derived from existing work [24|. 
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bridging the gap between different characteristics of reuse candidates and reuse needs, and (ii) 
derive additional criteria for useful reuse candidates based on characteristics of the reuse pro- 
cess itself. 

• Defined and rationalized so they can be easily tailored to specific project needs and 
characteristics: We want to be able to adjust a given reuse model and characterization 
scheme to changing project needs and characteristics in a systematic way. This requires not 
only the ability to change the scheme, but also some kind of rationale that ties the given reuse 
characterization scheme back to its underlying model and assumptions. Such a rationale 
enables us to identify the impact of different environments and modify the scheme in a sys- 
tematic way. 


3, EXISTING REUSE MODELS 

A number of research groups have developed (implicit) models and characterization schemes 
for reuse (e.g., [12, 14, 17, 26, 27]). The schemes can be distinguished as special purpose schemes 
and meta schemes. 

The large majority of published characterization schemes have been developed for a special 
purpose. They consist of a fixed number of characterization dimensions. There intention is to 
characterize software products as they exist. Typical dimensions for characterizing source code 
objects in a repository are ’function’, ’size’, or ’type of problem’. Example schemes include the 
schemes published in [14, 17], the ACM Computing Reviews Scheme, AFIPS’s Taxonomy of Com- 
puter Science and Engineering, schemes for functional collections (e.g., GAMS, SHARE, SSP, 
SPSS, IMSL) and schemes for commercial software catalogs (e.g., ICP, IDS, IBM Software Cata- 
log, Apple Book). It is obvious that special purpose schemes are not designed to satisfy the reuse 
modeling requirements of section 2.3. 
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A few characterization schemes can be instantiated for different purposes. They explicitly 
acknowledge the need for different schemes (or the expansion of existing ones) due to different or 
changing needs of an organization. They, therefore, allow the instantiation of any imaginable 
scheme. An excellent example is Ruben Prieto-Diaz’s facet-based meta-characterization scheme 
[18, 21]. Theoretically, meta schemes are flexible enough to allow the capturing of any reuse 
aspect. However, based on known examples of actual uses of meta schemes, such broadness has 
not been utilized. Instead, most examples focus on product reuse, are limited to the reuse candi- 
dates, and ignore the reuse process entirely. Meta schemes were not designed to satisfy the reuse 
modeling requirements of section 2.3. 

To illustrate the capabilities of existing schemes, we give the following instance of an exam- 
* 

pie meta scheme : 


• name: What is the product’s name? (e.g., buffer. ada, queue. ada, list, pascal) 

• function: What is the functional specification or purpose of the product? (e.g., integer queue, 
< element >_buffer, sensor control system) 

• type: What type of product is it? (e.g., requirements document, design document, code docu- 
ment) 

• granularity: What is the product’s scope? (e.g., system level, subsystem level, component 
level, module - package, procedure, function - level) 

• representation: How is the product represented? (e.g., informal set of guidelines, schematized 
templates, languages such as Ada) 

• input/output: What are the external input/output dependencies of the product needed to 
completely define/extract it as a self-contained entity? (e.g,, global data referenced by a code 
unit, formal and actual input/output parameters of a procedure, instantiation parameters of a 
generic Ada package) 

• application domain: What application classes was the product developed for? (e.g. ground 
support software for satellites, business software for banking, payroll software) 


• The scheme is applicable to all reuse product candidates. For example, a generic Ada package 
’buffer.ada’ may be characterized as having identifier ’buffer.ada’, offering the function 
’<element>^buffer’, being usable as a ’product’ of type ’code document’ at the ’package 
module level’, and being represented in ’Ada’. The self-contained definition of the package 
requires knowledge regarding the instantiation parameters as well as its visibility of externally 

* Characterization dimensions are marked with V; example categories for each dimension are listed in parentheses. 
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defined objects (e.g., explicit access through WITH clauses, implicit access according to nesting 
structure). In addition, effective use of the object may require some basic knowledge of the 
language Ada and assume thorough documentation of the object itself. It may have been 
developed within the application domain ’ground support software’, according to a ’waterfall 
life-cycle’ and ’functional decomposition design’, and exhibiting high quality in terms of ’relia- 
bility’. In order to characterize reuse candidates of type process or knowledge, new categories 
need to be generated. 

Such a scheme has typically been used to characterize reuse candidates only. However, in order 
to evaluate the reuse potential of a reuse candidate in a given reuse scenario, one needs to 
understand the distance between its characteristics and the stated or anticipated reuse needs. 
In the case of the Ada package example, the required function may be different, the quality 
requirements with respect to reliability may be higher, or the design method used in the current 
project may be different from the one according to which the package has been created origi- 
nally. Without understanding the distance to be bridged between reuse requirements and reuse 
candidates it is hard to (a) predict the cost involved in reusing a particular object, and (b) 
establish criteria for populating a reuse repository that supports cost-effective reuse. 

The scheme provides no information for characterizing the reuse process. To really predict the 
cost of reuse we do not only have to understand the distance to be bridged between reuse candi- 
dates and reuse needs, but also the intended process to bridge it (i.e., the reuse process). For 
example, it can be expected that it is easier to bridge the distance with respect to function by 
using a parameterized instantiation mechanism rather than modifying the existing package by 
hand. 

There is no explicit rationale for the eight dimensions of the example scheme. That makes it 
hard to reason about its appropriateness as well as modify it in any systematic way. There is 
no guidance in tailoring the example scheme to new needs with respect to what is to changed 
(e.g., only some categories, dimensions, or the entire implicitly underlying model) or how it is 



to be changed. For example, it is not clear what needs to be changed in order to make the 
scheme applicable to reuse candidates of type process or knowledge. 

In summary, existing schemes - special purpose as well as meta schemes - only partially 
satisfy the requirements laid out above. The most crucial shortcoming is the lack of rationales 
which makes it hard to tailor such schemes to changing needs and environment characteristics. 
This observation suggests the need for new, broader reuse models and characterization schemes. 
In the next section, we suggest a comprehensive reuse model and characterization schemes which 
satisfy all four requirements. 


4. A COMPREHENSIVE REUSE MODEL 

In this section we define a comprehensive reuse model and characterization schemes which 
satisfy the requirements stated in section 2.3. We start with a very general reuse model, refine it 
step by step until it generates reuse characterization dimensions at the level of detail needed to 
understand, evaluate, motivate or improve reuse. This modeling approach allows us to deal with 
the complexity of the modeling task itself, and document an explicit rationale for the resulting 
model. 

4*1* Reuse Model 

The comprehensive reuse model used in this section is consistent with the view of reuse 
represented in section 2.2. Reuse comprises the transformation of existing reuse candidates into 
needed objects which satisfy established reuse needs. The transformation is referred to as reuse 
process. Specifications of the needed objects are an essential part of the reuse needs which guide 
any reuse process. 
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REUSE CANDIDATES REUSE PROCESS NEEDED OBJECTS 

Figure 3: Abstract Reuse Model (Refinement level 0) 

The reuse candidates represent experience from the same project, prior projects, or other sources, 
that have been evaluated as being of potential reuse value, and have been made available in some 
form of experience base. The reuse needs specify objects needed in the current project. In the 
case of successful reuse, these needed objects would be the potentially modified versions of reuse 
candidates. Both the reuse candidate and reuse needs may refer to any type of experience accu- 
mulated in the context of software projects ranging from products to processes to knowledge. 

The reuse process transforms reuse candidates into objects which satisfy given reuse needs. 

In order to better understand reuse related issues we refine each component of the reuse 
model further. The result of this first refinement step is depicted in Figure 4. 
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REUSE CANDIDATES REUSE PROCESS NEEDED OBJECTS 

Figure 4: Our Reuse Model (Refinement level 1) 


Each reuse candidate is a specific object considered for reuse. The object has various attri- 
butes that describe and bound it. Most objects are physically part of a system, i.e. they interact 
with other objects to create some greater object. If we want to reuse an object we must under- 
stand its interaction with other objects in the system in order to extract it as a unit, i.e. object 
interface . Objects were created in some environment which leaves its characteristics on the 
object, even though those characteristics may not be visible. We call this the object context. 

Given reuse needs may be satisfied by a set of reuse candidates. Therefore, we may have to 
consider different attributes. The system in which the transformed object is integrated and the 
system context in which the system is developed must also be classified. 

The reuse process is aimed at extracting a reuse candidate from a repository based on the 
characteristics of the known reuse needs, and making it ready for reuse in the system and context 
in which it will be reused. We must describe the various reuse activities and classify them. The 
reuse activities need to be integrated into the reuse-enabling software development process. The 
means of integration constitute the activity interface. Reuse requires the transfer of experience 
across project boundaries. The organizational support provided for this experience transfer is 
referred to as activity context . 


- 15 - 










Based upon the goals for the specific project, as well as the organization, we must assess (i) 
the required qualities of the reused object as stated by the reuse needs, (ii) the quality of the reuse 
process, especially its integration into the enabling software evolution process, and (iii) the quality 
of the existing reuse candidates. 

4.2. Model— Based Reuse Characterization Scheme 

Each component of the First Model Refinement (Figure 4) is further refined as depicted in 
Figures 5(a-c) . It needs to be noted that these refinements are based on our current understand- 
ing of reuse and may, therefore, change in the future. 

4.2.1. Reuse Candidates 

In order to characterize the object itself, we have chosen to provide the following six dimen- 
sions and supplementing categories: the object’s name (e.g., buffer.ada), its function (e.g., 
integer_buffer), its possible use (e.g., product), its type (e.g., requirements document), its granu- 
larity (e.g., module), and its representation (e.g., Ada language). The object interface consists of 
such things as what are the explicit inputs /outputs needed to define and extract the object as a 
self-contained unit (e.g., instantiation parameters in the case of a generic Ada package), and what 
are additionally required assumptions and dependencies (e.g., user’s knowledge of Ada). Whereas 
the object and object interface dimensions provide us with a snapshot of the object at hand, the 
object context dimension provides us with historical information such as the application classes 
the object was developed for (e.g., ground support software for satellites), the environment the 
object was developed in (e.g., waterfall life-cycle model), and its validated or anticipated quality 
(e.g., reliability). 

The resulting model refinement is depicted in Figure 5a. 
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- name 

— function 

— use 

- type 

- granularity 

— representation 


— input /output 

— dependencies 


— application domain 

— solution domain 

— object quality 


Figure 5a; Reuse Model (Reuse Candidates / Refinement level 2) 


Each reuse candidate is characterised in terms of 

• name: What is the object’s name? (e.g., buffer. ada, seMnspection, sel_cost_model) 

• function: What is the functional specification or purpose of the object? (e.g., integer_queue, 
< element >_buffer, sensor control system, certify appropriateness of design documents, 
predict project cost) 

• use: How can the object be used? (e.g,, product, process, knowledge) 

• type: What type of object is it? (e.g., requirements document, code document, inspection 
method, coding method, specification tool, graphic tool, process model, cost model) 

• granularity: What is the object’s scope? (e.g., system level, subsystem level, component 
level, module - package, procedure, function - level, entire life cycle, design stage, coding 
stage) 

• representation: How is the object represented? (e.g., data, informal set of guidelines, 
schematized templates, formal mathematical model, languages such as Ada, automated tools) 

• input/output: What are the external input/output dependencies of the object needed to 
completely define/extract it as a self-contained entity? (e.g., global data referenced by a 
code unit, formal and actual input/output parameters of a procedure, instantiation parame- 
ters of a generic Ada package, specification and design documents needed to perform a design 
inspection, defect data produced by a design inspection, variables of a cost model) 

• dependencies: What are additional assumptions and dependencies needed to understand the 
object? (e.g., assumption on user’s qualification such as knowledge of Ada or qualification to 
read, specification document to understand a code unit, readability of design document, 
homogeneity of problem classes and environments underlying a cost model) 

• application domain: What application classes was the object developed for? (e.g. ground 
support software for satellites, business software for banking, payroll software) 

• solution domain: What environment classes was the object developed in? (e.g., waterfall 
life-cycle model, spiral life-cycle model, iterative enhancement life-cycle model, functional 
decomposition design method, standard set of methods) 

• object quality: What qualities does the object exhibit? (e.g., level of reliability, correctness, 
user-friendliness, defect detection rate, predictability) 
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A subset of this scheme has been used in Section 3. In contrast to Section 3, we now have 
(i) a rationale for these dimensions (see Figure 5a) and (ii) understand that they cover only part 
(i.e., the reuse candidate) of the comprehensive reuse model depicted in Figure 4. 

4*2*2. Needed Objects 

In order to characterize the needed objects (or reuse needs), we have chosen the same eleven 
dimensions and supporting categories as for the reuse candidates. The resulting model refinement 
is depicted in Figure 5b: 



— name 

— function 

- use 

- type 

- granularity 

— representation 


— input/output 

— dependencies 


— application domain 

— solution domain 

— object quality 


Figure 5b: Reuse Model (Reuse Needs / Refinement level 2) 


However, an object may change its characteristics during the actual process of reuse. 
Therefore, its characterizations before and after reuse can be expected to be different. For exam- 
ple, a reuse candidate may be a compiler (type) product (use), and may have been developed 
according to a waterfall life-cycle approach (solution domain). The needed object is a compiler 
(type) process (use) integrated into a project based on iterative enhancement (solution domain). 


- 18 - 



This means that despite the similarity between the refined models of reuse candidates and 
needed objects, there exists a significant difference in emphasis: In the former case the emphasis is 
on the potentially reusable objects themselves; in the latter case, the emphasis is on the system in 
which these object(s) are (or are expected to be) reused. This explains the use of different dimen- 
sion names: ’system* and ’system context’ instead of ’object interface* and ’object context’. 

The distance between the characteristics of a reuse candidate and the needed object give an 
indication of the gap to be bridged in the event of reuse. 

4.2.3* Reuse Process 

The reuse process consists of several activities. In the remainder of this paper, we will use a 
model consisting of four basic activities: identification, evaluation, modification, and integration. 
In order to characterize each reuse activity we may be interested in its name (e.g., modify.pl), its 
function (e.g., modify an identified reuse candidate to entirely satisfy given reuse needs), its type 
(e.g., identification, evaluation, modification), and the mechanism used to perform its function 
(e.g., modification via parameterization). The interface of each activity may consist of such 
things as the explicit input/output interfaces between the activity and the enabling software evo- 
lution environment (e.g., in the case of modification: performed during the coding phase, assumes 
the existence of a specification), and other assumptions regarding the evolution environment that 
need to be satisfied (e.g., existence of certain configuration control policies). The activity context 
may include information about how reuse candidates are transferred to satisfy given reuse needs 
(experience transfer), and the quality of each reuse activity (e.g., reliability, productivity). 

This refinement of the reuse process is depicted in Figure 5c, 
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REUSE PROCESS 


name 

function 

type 

mechanism 


input/output 

dependencies 


experience transfer 
reuse quality 


Figure 5c: Reuse Model (Reuse Process / Refinement level 2) 


In more detail, the dimensions and example categories for characterizing the reuse process are: 

• REUSE PROCESS: For each reuse activity characterize: 

+ Activity: 

- name: What is the name of the activity? (e.g., identify .generics, evaluate. generics, 
modify. generics, integrate. generics) 

- function: What is the function performed by the activity? (e.g., select candidate objects 
{x*} which satisfy certain characteristics of the reuse needs 5 5T; evaluate the potential of 
the selected candidate objects of satisfying the given system and system context dimensions 
of the reuse needs ’J 1 and pick the most suited candidate ’x^*; modify ’xj/ to entirely 
satisfy T*; integrate object V into the current development project) 

- type: What is the type of the activity? (e.g., identification, evaluation, modification, 
integration) 

- mechanism: How is the activity performed? (in the case of identification: e.g., by name, 
by function, by type and function; in the case of evaluation: e.g., by subjective judgement, 
by evaluation of historical baseline measurement data; in the case of modification: e.g., 
verbatim, parameterized, template-based, unconstrained; in the case of integration: e.g., 
according to the system configuration plan, according to the project/process plan) 

+ Activity Interface: 

- input /output: What are explicit input and output interfaces between the reuse activity 
and the enabling software evolution environment? (in the case of identification: e.g., 
description of reuse needs / set of reuse candidates; in the case of modification: e.g., one 
selected reuse candidate, specification for the object to be reused / object to be reused) 

- dependencies: What are other implicit assumptions and dependencies on data and infor- 
mation regarding the software evolution environment? (e.g., time at which reuse activity 
is performed - relative to the enabling development process: e.g., during design or coding 
stages; additional information needed to perform the reuse activity effectively: e.g,, pack- 
age specification to instantiate a generic package, knowledge of system configuration plan, 
configuration management procedures, or project plan) 

-f Activity Context: 

- experience transfer: What are the support mechanisms for transferring experience across 
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projects? (e.g,, human, experience base, automated) 

- reuse quality: What is the quality of each reuse activity? (e.g., high reliability, high 
predictability of modification cost, correctness, average performance) 


4,3. Example Applications of the Comprehensive Reuse Model 

We demonstrate the applicability of our model-based reuse scheme by characterizing the 
three hypothetical reuse scenarios which have been used informally throughout this paper: Ada 
generics, design inspections, and cost models. The resulting characterizations are summarized in 
tables 1, 2, and 3: 


- 21 - 



Reuse Examples 

Dimensions 

Ada generic 

design inspection 

cost model 

name 

buffer. ada 

sel_inspection. waterfall 

sel_cost_model. fortran 

function 

< element >_b utter 

certify appropriateness 
of design documents 

predict 
project cost 

use 

product 

process 

knowledge 

type 

code document, 

inspection method 

cost model 

granularity 

package 

design stage 

entire life cycle 

representation 

Ada/ 

generic package 

informal set of 
guidelines 

formal mathematical 
model 

input/output 

formal and actual 
instantiation params 
(type and number) 

specification and 
design document needed, 
defect data produced 

estimated product 
size in KLOC, 
complexity rating, 
methodology level, 
cost in staff_hours 

dependencies 

assumes Ada knowledge 

assumes a readable design, 
qualified reader 

assumes a relatively 
homogeneous class 
of problems and environments 

application domain 

ground support 
sw for satellites 

ground support 
sw for satellites 

ground support 
sw for satellites 

solution domain 

waterfall (Ada) 
life-cycle model, 
functional de- 
composition design 
method 

waterfall (Ada) 
life-cycle model, 
standard set of 
methods 

waterfall (Ada) 
life-cycle model 
standard set of 
methods 

object quality 

high reliability 

(e.g., < 0.1 defects 
per KLoC for a given 
set of acceptance tests) 

average defect 
detection rate 
(e.g., > 0.5 defects 
detected per stafMiour) 

average predictability 

(e.g., < 10% pre- 
diction error) 


Table 1: Characterizations of Reuse Candidates 
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Reuse Examples 

Dimensions 

Ada generics 

design inspection 

cost model 

name 

string_buffer.ada 

sel_inspection.deanroom 

sel_cost_model.ada 

function 

string_buffer 

certify appropriateness 
of design documents 

predict 
project cost 

use 

product 

process 

knowledge 

type 

code document, 

inspection method 

cost model 

granularity 

package 

design stage 

entire life cycle 

representation 

Ada 

informal set of 
guidelines 

formal mathematical 
model 

input/output 

formal and actual 
instantiation params 
(type and number) 

specification and 
design document needed, 
defect data produced 

estimated product 
size in KLOC, 
complexity rating, 
methodology level, 
cost in staffjiours 

dependencies 

assumes Ada knowledge 

assumes a readable design, 
qualified reader 

assumes a relatively 
homogeneous class 
of problems and environments 

application domain 

ground support 
sw for satellites 

ground support 
sw for satellites 

ground support 
sw for satellites 

solution domain 

waterfall (Ada) 
life-cycle model, 
object oriented 
design method 

Cleanroom (Fortran) 
development model, 
stepwise refinement 
oriented design, 
statistical testing 

waterfall (Ada) 
life-cycle model, 
revised set of 
methods 

object quality 

high reliability 

(e.g., < 0,1 defects 
per KLoC for a given 
set of acceptance tests), 
high performance 
(e.g., max. response times 
for a set of tests) 

high defect 
detection rate 
(e.g., > 1.0 defects 
detected per staff_hour) 
wrt. interface faults 

high predictability 

(e.g., < 5 % pre- 
diction error) 


Table 2: Characterizations of Needed Objects 
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Reuse Examples 

Dimensions 


Ada generics 

design inspection 

cost model 

name 


modify .generics 

modify .inspections 

modify.cost_models 

function 


modify to satisfy 
target specification 

modify to satisfy 
target specification 

modify to satisfy 
target specification 

type 


modification 

modification 

modification 

mechanism 


parameterized 
(generic mechanism) 

unconstrained 

template-based 

input/output 


buffer.ada, 
reuse specification/ 
string_buffer,ada 

sel_inspection.waterfall, 
reuse specification/ 
seMnspection.cleanroom 

sel_cost_model. fortran, 
reuse specification/ 
sel_cost_mo del ,ad a 

dependencies 


performed 

during coding stage, 
package specification 
needed, 

performed 

during planning stage, 

performed 

during planning stage, 



knowledge of 
system configuration 
plan 

knowledge of 
project plan 

knowledge of historical 
Ada project profiles 

experience transfer 

! 

automated 

human and 
experience base 

experience base 

reuse quality 


correctness 

correctness 

correctness 


Table 3: Characterizations of Reuse Processes 













5. SUPPORT MECHANISMS FOR COMPREHENSIVE REUSE 


According to the reuse oriented software development model depicted in Figure 2, effective 
reuse needs to take place in an environment that supports continuous improvement, i.e., record- 
ing of experience across all projects, appropriate packaging and storing of recorded experience, 
and reusing existing experience whenever feasible. In the TAME project at the University of 
Maryland, such an environment model has been proposed and (partial) prototype environments 
are currently being built according to this model. In the remainder of this section, we introduce 
the reuse oriented TAME environment model, discuss a number of mechanisms for effective reuse, 
and introduce several prototype environments being built according to the TAME model. 

5.1. The Reuse Oriented TAME Environment Model 

The important components of the reuse oriented TAME environment model are depicted in 
Figure 6: the project organization which performs individual development projects, the experience 
base which stores and actively modifies development experience from all projects, and the 
mechanisms for learning and reuse. The shaded areas in Figure 6 indicate how the reuse model of 
Figure 3 intersects with the TAME environment model. 
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I 

1 

! 


REUSE ORIENTED SOFTWARE ENVIRONMENT MODEL 



Figure 6; Reuse Oriented Software Environment Model 


Within the project organization each development project is performed according to the 
quality improvement paradigm [3, 9], The quality improvement paradigm consists of the follow- 
ing steps: 


- 20 - 









1. Plan: Characterize the current project environment so that the appropriate past experience 
can be made available to the current project. Set up the goals for the project and refine them 
into quantifiable questions and metrics for successful project performance and improvement 
over previous project performances (e.g., based upon the goal/question/metric paradigm [9, 
13]). Choose the appropriate software development process model for this project with the sup- 
porting methods and tools - for both construction and analysis. 

2. Execute: Construct the products according to the chosen development process model, methods 
and tools. Collect the prescribed data, validate and analyze it to provide feedback in real-time 
for corrective action on the current project. 

3. Package: Analyze the data in a post-mortem fashion to evaluate the current practices, deter- 
mine problems, record findings and make recommendations for improvement for future pro- 
jects. Package the experiences in the form of updated and refined models and other forms of 
structured knowledge gained from this and previous projects, and save it in an experience base 
so it can be available to future projects. 

The experience base contains reuse candidates of different types, granularity and representa- 
tion. Example entries in the case of the examples described in section 4.3 include objects of type 
’code document’, granularity ’package’ and representation ’Ada’; objects of type ’inspection 
method’, granularity ’design stage’ and representation ’schematized template’; and objects of type 
’cost model’, granularity ’entire life cycle’ and representation ’formal mathematical model’. 

During each step of a development project performed according to the quality improvement 
paradigm reuse needs are identified and matches made against reuse candidates available in the 
experience base. During the characterization step, characteristics of the current project environ- 
ment can be used to identify appropriate past experience in the experience base, e.g. based on 
project characteristics the appropriate instantiation of a cost model can be generated. During the 
planning step, project goals can be used to identify existing similar goal/question/metric models 
or process/product/quality models in the experience base, e.g., based on project goals a 
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goal/question/ metric model can be chosen for evaluating a design inspection method. During the 
execution step, product specifications can be used to identify existing components from prior pro- 
jects, such as Ada generics. During the feedback step, the analysis goals generated during plan- 
ning are used as the basis of analysis by fitting baselines to compare against the current data. As 
part of the feedback step a decision is made as to which experiences are worth recording. The 
degree of guidance that can be provided for entering reuse candidates into the experience base 
depends upon the accumulated knowledge of expected reuse requests for future projects. 

The experience base is part of an active organizational entity, referred to a the Experience 
Factory [4], that supports project developments by analyzing and synthesizing all kinds of experi- 
ence, acting as a repository for such experience, and supplying that experience to various projects 
on demand. In the context of the reuse oriented software environment model, the Experience Fac- 
tory not only stores experience in a variety of repositories, but performs the constant modification 
of experience to increase its reuse potential. Example modifications address the formalization of 
experience (e.g., building a cost model empirically based upon the data available), tailoring of 
experience to fit the needs of a specific project (e.g., instantiating an Ada package from a generic 
package), and the generalizing of experience to be applicable across project classes (e.g., develop- 
ing a generic package from a specific package). It plays the role of an organizational ’server 5 
aimed at satisfying project specific reuse requests effectively [4]. The constant collection of meas- 
urement data regarding reuse needs and the reuse processes themselves enables the judgements 
needed to populate the experience base effectively and select the best suited reuse candidates. 
The use of the quality improvement paradigm within the project organization enables the integra- 
tion of measurement-based analysis and construction. 

5*2* Mechanisms to Support Effective Reuse in the TAME Environment Model 

Improvement in the reuse oriented TAME environment model of Figure 6 is based on the 
feedback of experience captured from prior projects into ongoing and future software develop- 
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ments. The mechanisms needed to support effective feedback are listed in Figure 7. 


feed back 



record package identify evaluate modify 

Figure 7; Mechanisms needed to Support Effective Feedback of Experience 


Feedback requires learning and reuse. Although learning and reuse are possible in any 
environment, we are interested in addressing and supporting them explicitly and systematically. 
Systematic learning requires support for the recording of experience in some experience base and 
its packaging in order to increase its reuse potential for anticipated reuse needs in future develop- 
ments. Systematic reuse requires support for the identification of candidate experience, its 
evaluation, and modification. 

Reuse and learning are possible in any environment. However, we want learning and reuse 
to be explicitly planned, not implicit or coincidental. In the reuse oriented software development 
environment, learning and reuse are explicitly modeled and become desired characteristics of 
software development. They are specific processes performed in conjunction with the Experience 
Factory. 

5»2«1* Recording of Experience 

The objective of recording experience is to create a repository of well specified and organ- 
ized experience. This requires a precise characterization of the reuse candidates to be recorded, 
the design and implementation of a comprehensive experience base, and effective mechanisms for 
collecting, qualifying, storing and retrieving experience. The characterization of reuse candidates 
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is derived from characterizations of known reuse needs and reuse processes. The characterization 
of reuse candidates describes what information needs to be stored in addition to the objects them- 
selves in order to make them reusable, and how it should be packaged. The experience base 
replaces the project database of traditional environment models by the more comprehensive con- 
cept of an experience base which is intended to capture the entire body of experience recorded 
during the planning and execution steps of all software projects within an organization. 

Examples of recording experience include the storing of Ada generics, design inspection 
methods, and cost models. Based on our reuse model, Table 1 describes the information needed 
in conjunction with each of these object types in order to make them likely reuse candidates to 
satisfy the hypothetical reuse needs using the hypothetical reuse processes described in Tables 2 
and 3, respectively. For example, in the case of Ada generics, we may require each object to be 
augmented with information on the number of instantiation parameters, the application and solu- 
tion domain, and the expected or demonstrated reliability. If we can quantify such information 
(e.g., Ada generics developed within ground support software projects, Ada generics with less than 
5 instantiation parameters are acceptable), we can use it to exclude inappropriate objects from 
being recorded in the first place. 

5.2.2. Packaging of Experience 

The objective of packaging experience is to increase its reuse potential. This requires a pre- 
cise characterization of the new reuse needs or processes, and effective mechanisms for generaliz- 
ing, generalizing and formalizing experience. Packaging may take place at the time of first 
recording experience into the experience base or at any later time when new reuse needs reuse 
needs become known or our understanding of the interrelationship between reuse candidates, 
reuse needs and reuse processes changes. 

The objective of generalizing existing experience prior to its reuse is to make a candidate 
reuse object useful in a larger set of potential target applications. The objective of tailoring exist- 
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mg experience prior to its potential reuse is to fine-tune a candidate reuse object to fit a specific 
task or exhibit special attributes, such as size or performance. The objective of formalizing exist- 
ing experience prior to its actual reuse is to increase the reuse potential of reuse candidates by 
encoding them in more precise, better understood ways. These activities require a well- 
documented cataloged and categorized set of reuse candidates, mechanisms that support the 
modification process, and an understanding of the potential reuse needs. Generalization and 
tailoring are specifically concerned with changing the application and solution domain characteris- 
tics of reuse candidates: from project specific to domain specific to project specific and vice versa. 
Objectives and characteristics are different from project to project, and even more so from 
environment to environment. We cannot reuse past experience without modifying it to the needs 
of the current project. The stability of the environment in which reuse takes place, as well as the 
origination of the experience, determine the amount of tailoring required. Formalization activities 
are concerned with movement across the boundaries of the representation dimension within the 
experience base: from informal to schematized and then to formal. 

Examples of tailoring experience include the instantiation of a set of specific Ada packages 
from a generic package available in an object oriented experience base, the fine-tuning of a cost 
model to the specific characteristics of a class of projects, and the adjustment of a design inspec- 
tion method to focus on the class of defects common to the application. Examples of generalizing 
experience include the creation of a generic Ada package from a set of specific Ada packages, the 
creation of a general cost model from a set of domain specific cost models, and the definition of 
an application and solution domain specific design inspection method based on the experience 
with design inspections in a number of specific projects. Examples of formalization include the 
writing of functional specifications for generic Ada packages, providing automated support for 
checking adherence to entry and exit criteria of a design inspection method, and building a cost 
model empirically based upon the data available in an experience base. 
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A misunderstanding of the importance of tailoring exists in many organizations. These 
organizations have specific development guidebooks which are of limited value because they ’are 
written for some ideal project’ which ’has nothing in common with the current project and, there- 
fore, do not apply’. All guidebooks (including standards such as DOD-STD-2167) are general and 
need to be tailored to each project in order to be effective. 

5.2*3. Identification of Candidate Experience 

The objective of identifying candidate experience is to find a set of candidates with the 
potential to satisfy project specific reuse needs. This requires a precise characterization of the 
reuse needs, some organizational scheme for the reuse candidates available in the experience base, 
and an effective mechanism for matching characteristics of the project specific reuse needs against 
the experience base. 

Let’s assume, for example, that we need an Ada package which implements a ’string_buffer’ 
with high ’reliability and performance’ characteristics. This need may have been established dur- 
ing the project planning phase based on domain analysis, or during the design or coding stages. 
We identify candidate objects based on some subset of the object related characteristics stated in 
Table 2: string_buffer.ada, string_buffer, product, code document, package, Ada [28]. The more 
characteristics we use for identification, the smaller the resulting set of candidate objects will be. 
For example, if we include the name itself, we will either find exactly one object or none. 
Identification may take place during any project stage. We will assume that the set of success- 
fully identified reuse candidates contains ’buffer.ada’, the object characterized in Table 1. 

6.2.4* Evaluation of Experience 

The objective of evaluating experience is to characterize the degree of discrepancies between 
a given set of reuse needs (see Table 2) and some identified reuse candidate (Table l), and (ii) 
predict the cost of bridging the gap between reuse candidates and reuse needs. The first type of 
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evaluation goal can be achieved by capturing detailed information about reuse candidates and 
reuse needs according to the dimensions of the presented characterization scheme. The second 
goal requires the inclusion of data characterizing the reuse process itself and past experience about 
similar reuse activities. Effective evaluation requires precise characterization of reuse needs, reuse 
processes and reuse candidates; knowledge about their relationships, and effective mechanisms for 
measurement. 

The knowledge regarding the interrelationship between reuse needs, processes and candi- 
dates is the result of the proposed evolutionary learning which takes place within the reuse 
oriented TAME environment model. The mechanisms used for effective measurement are based 
on the goal/question/metric paradigm [9, 11, 13]. It provides templates for guiding the selection 
of appropriate metrics based on a precise definition of the evaluation goal. Guidance exists at the 
level of identifying certain types of metrics (e.g., to quantify the object of interest, to quantify the 
perspective of interest, to quantify the quality aspect of interest). Using the goal/question/metric 
paradigm in conjunction with reuse characterizations like the ones depicted in Tables 1, 2, and 3, 
provides very detailed guidance as to what exact metrics need to be used. For example, evaluation 
of the Ada generic example suggests metrics to characterize discrepancies between the reuse needs 
and all available reuse candidates in terms of (i) function, use, type, granularity, and representa- 
tion on a nominal scale defined by the respective categories, (ii) input/output interface on an 
ordinal scale ’number of instantiation params’, (iii) application and solution domains on nominal 
scales, and (iv) qualities such as performance based on benchmark tests. 

For example, we want to evaluate the reuse potential of the object ’buffer. ada’ identified in 
the previous subsection. We need to evaluate whether and to what degree ’buffer.ada’ (as well as 
any other identified candidate) needs to be modified and estimate the cost of such modification 
compared to the cost required for creating the desired object ’string_buffer’ from scratch. Three 
characteristics of the chosen reuse candidate deviate from the expected ones: it is more general 
than needed (see function dimension), it has been developed according to a different design 


- 33 - 


approach (see solution domain dimension), and it does not contain any information about its per- 
formance behavior (see object quality dimension). The functional discrepancy requires instantiat- 
ing object ’buffer.ada’ for data type ’string 1 . The cost of this modification is extremely low due 
to the fact that the generic instantiation mechanism in Ada can be used for modification (see 
Table 3). The remaining two discrepancies cannot be evaluated based on the information avail- 
able through the characterizations in section 4.3. On the one hand, ignoring the solution domain 
discrepancy may result in problems during the integration phase. On the other hand, it may be 
hard to predict the cost of transforming ’buffer.ada 1 to adhere to object oriented principles. 
Without additional information about either the integration of non-object oriented packages or 
the cost of modification, we only have the choice between two risks. Predicting the cost of 
changes necessary to satisfy the stated object performance requirements is impossible because we 
have no information about the candidate’s performance behavior. It is noteworthy that very often 
practical reuse seems to fail because of lack of appropriate information to evaluate the reuse 
implications a-priori, rather than because of technical infeasibility [15], 

The characterization of both reuse candidates and needs and the reuse process allow us to 
understand some of the implications and risks associated with discrepancies between identified 
reuse candidates and target reuse needs. Problems arise when we have either insufficient informa- 
tion about the existence of a discrepancy (e.g., object performance quality in our example), or no 
understanding of the implications of an identified discrepancy (e.g., solution domain in our exam- 
ple). In order to avoid the first type of problem, one may either constrain the identification pro- 
cess further by including characteristics other than just the object related ones, or not have any 
objects without ’performance 1 data in the reuse repository. If we had included ’desired solution 
domain 1 and ’object performance’ as additional criteria in our identification process, we may not 
have selected object ’buffer.ada’ at all. If every object in our repository would have performance 
data attached to it, we at least would be able to establish the fact that there exists a discrepancy. 
In order to avoid the second type of problem, we need have some (semi-) automated modification 
mechanism, or at least historical data about the cost involved in similar past situations. It is 
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clear that in our example any functional discrepancy within the scope of the instantiation param- 
eters is easy to bridge due to the availability of a completely automated modification mechanism 
(i.e., generic instantiation in Ada). Any functional discrepancy that cannot be bridged through 
this mechanisms poses a larger and possibly unpredictable risk. Whether it is more costly to re- 
design ’buffer, ada’ in order to adhere to object oriented design principles or to re-develop it from 
scratch is not obvious without past experience. A mechanism for modeling all kinds of experience 
is given in [6], 

5.2.5. Modification of Experience 

The objective of modifying experience is to bridge the gap between a selected reuse candi- 
dates and given reuse needs. This requires a precise characterization of the reuse needs, and effec- 
tive mechanisms for modification. Technically, modification mechanisms are very similar to the 
tailoring (and generalization) mechanism introduced for packaging experience. Tailoring here is 
different in that during modification the target is described by concrete, project specific reuse 
needs, whereas during packaging the target is typically imprecise in that it reflects anticipated 
reuse needs in a class of future projects. We refer to tailoring (and generalizing) as ’off-line’ 
(during packaging) or ’on-line’ (during modification) depending on whether it takes place before 
or as part of a concrete instance of reuse. 

Examples of modifying experience - similar to the examples given earlier for tailoring - 
include the instantiation of a set of specific Ada packages from a generic package available in an 
object oriented experience base, the fine-tuning of a cost model to the specific characteristics of a 
class of projects, and the adjustment of a design inspection method to focus on the class of defects 
common to the application. 
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5.3. TAME Environment Prototypes 


In the TAME (Tailoring A Measurement Environment) project, we investigate fundamental 
issues related to the reuse- (or improvement-) oriented software environment model of Figure 6 
and build a series of (partial) research prototype versions [8, 9, 15]. 

Current research topics include the formalization of the goal/question/metric paradigm for 
effective software measurement and evaluation; the development of formalisms for representing 
software engineering experience such as quality models, lessons learned, process models, product 
models; the development of models for packaging experience in the experience base; and the 
development of effective mechanisms to support learning and reuse within the experience factory 
(e.g., qualification, formalization, tailoring, generalization, synthesis). In addition, various slices 
of an evolving TAME environment are being prototyped in order to study the definition and 
integration of different concepts. 

Aspects of the TAME research prototypes, currently being developed at the University of 
Maryland, can be classified best by the different classes of experience they attempt to generate, 
maintain and reuse: 

• Support for identifying objects by browsing through projects, goals and processes based on a 
facet-based characterization mechanism. 

• Support for the generalization, tailoring, and integration of a variety experience types based on 
an object oriented experience base model. 

• Support for the definition of environment specific cost and resource allocation models and their 
tailoring, generalization and formalization based on project experience. 

• Support for the definition of test techniques in terms of entry and exit criteria that provides a 
method for selecting the appropriate technique for each project phase based on environment 
characteristics, data models, and project goals. 

• Support for the definition of process models and their formalization, generalization and tailor- 
ing based on project experience. 


- 35 - 


• Support for an experience factory architecture that supports the evolution of the organization. 


6« CONCLUSIONS 

We have introduced a comprehensive reuse framework consisting of reuse models, model- 
based characterization schemes, the TAME environment model supporting the integration of 
reuse into software development, and ongoing research and development efforts toward a TAME 
environment prototype. 

The presented reuse model and related model-based characterization schemes have advan- 
tages over existing models and schemes in that they (a) allow us to capture the reuse of any type 
of experience, (b) address reuse candidates and reuse needs as well as the reuse process itself, and 
(c) provide a rationale for the chosen characterizing dimensions. We have demonstrated the 
advantages of such a comprehensive reuse model and related schemes by applying them to the 
characterization of example reuse scenarios. Especially their usefulness for defining and motivat- 
ing the support mechanisms for comprehensive reuse and learning were stressed. 

Finally, we introduced the TAME environment model which supports the integration of 
reuse into software developments. Several partial instantiations of the TAME environment 
model, currently being developed at the University of Maryland, have been mentioned. In order 
to make reuse a reality, more research is required towards understanding and conceptualizing 
activities and aspects related to reuse, learning and experience factory technology. 
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